home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-glenn-layer-security-00.txt < prev    next >
Text File  |  1993-09-28  |  60KB  |  1,536 lines
  1.  
  2. Internet Engineering Task Force                              K. R. Glenn
  3. INTERNET-DRAFT                                                      NIST
  4.                                                        September 23,1993
  5.  
  6.  
  7.                Integrated Network Layer Security Protocol
  8.  
  9.  
  10.                         K. Robert Glenn (NIST)
  11.                         glenn@osi.ncsl.nist.gov
  12.  
  13.  
  14.                         Status of This Memo
  15.  
  16.  
  17. This document is an Internet-Draft.  Internet-Drafts are working
  18. documents of the Internet Engineering Task Force (IETF), it's Areas,
  19. and it's Working Groups.  Note that other groups may also distribute
  20. working documents as Internet-Drafts.
  21.  
  22. Internet-Drafts are draft documents valid for a maximum of six months.
  23. Internet-Drafts may be updated, replaced, or obsoleted by other
  24. documents at any time.  It is not appropriate to use Internet-Drafts as
  25. reference material or to cite them other than as a "working draft" or
  26. "work in progress."
  27.  
  28. To learn the status of any Internet-Draft, please check the
  29. 1id-abstract.txt listing contained in the Internet-Drafts Shadow
  30. Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
  31. ftp.nisc.sri.com, or munnari.oz.au.
  32.  
  33. It is intended that this document will be submitted to the IESG for
  34. consideration as a standards document.  Distribution of this document
  35. is unlimited.
  36.  
  37.                             ABSTRACT
  38.  
  39. The Internet has been moving towards a more standardized and open
  40. infrastructure to cope with its growing requirements.  One requirement
  41. of particular interest and importance is that of network security.
  42. With the possible addition of CLNP [ISO8473] as a connectionless
  43. network protocol for the Internet the most useful solution is an
  44. integrated network security protocol that will provide security
  45. services and mechanisms for both IP and CLNP.
  46.  
  47. The protocol defined by this Internet Draft is used to provide security
  48. services in support of an instance of communication between network
  49. layer entities for either IP or CLNP.  An attempt is made to keep the
  50. functionality as close as possible to [ISO11577].  As a result this
  51. specification contains all of the technical complexities and problems
  52. of [ISO11577].  Editorial comments are included to address certain
  53. technical issues, such as headers ending on word boundaries,
  54. type-length-value encoding problems, etc.  that may be outside the
  55. scope of [ISO11577].  This specification should be viewed as an initial
  56. attempt at identifying a protocol that can provide a set of security
  57. services for both IPV4 and CLNP.
  58.  
  59. K. R. Glenn          Expires: March 28,1994                     [Page 1]
  60.  
  61. INTERNET-DRAFT               I-NLSP                    September 23,1993
  62.  
  63. 1  Introduction
  64.  
  65. The Internet has been moving towards a more standardized and open
  66. infrastructure to cope with its growing requirements.  One requirement
  67. of particular interest and importance is that of network security.
  68. With the possible addition of CLNP as a connectionless network protocol
  69. for the Internet the obvious solution is an integrated network security
  70. protocol that will provide security services and mechanisms for both IP
  71. and CLNP.
  72.  
  73. The protocol defined by this Internet Draft is used to provide security
  74. services in support of an instance of communication between network
  75. layer entities for either IP or CLNP.  An attempt is made to keep the
  76. functionality as close as possible to [ISO11577].  As a result this
  77. specification contains all of the technical complexities and problems
  78. of [ISO11577].  Editorial comments are included to address certain
  79. technical issues, such as headers ending on word boundaries,
  80. type-length-value encoding problems, etc.  that may be outside the
  81. scope of [ISO11577].  This specification should be viewed as an initial
  82. attempt at identifying a protocol that can provide a set of security
  83. services for both IPV4 and CLNP.
  84.  
  85.  
  86. 2  Scope and Field of Application
  87.  
  88. This Internet Draft specifies a protocol to be used by End Systems and
  89. Intermediate Systems in order to provide security services in either
  90. the Network layer of the OSI protocol suite or the IP layer of the
  91. TCP/IP protocol suite.  The protocol defined in this Internet Draft is
  92. called the Integrated Network Layer Security protocol (I-NLSP).
  93.  
  94. This Internet Draft specifies the following services:
  95.  
  96.  1. data origin authentication
  97.  2. access control
  98.  3. connectionless confidentiality
  99.  4. traffic flow confidentiality 
  100.  5. connectionless integrity
  101.  
  102. Although the degree of protection afforded by some security services
  103. depends on the use of some specific cryptographic techniques, correct
  104. operation of this protocol is not dependent on the choice of a
  105. particular encipherment or decipherment algorithm;  that is left as a
  106. local matter for the communicating systems.  Furthermore, neither the
  107. choice nor the implementation of a specific security policy are within
  108. the scope of this Internet Draft.  The choice of a specific security
  109. policy, and hence the degree of protection that will be achieved, is
  110. left as a local matter among the systems that are using a single
  111. instance of secure communications.
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. K. R. Glenn          Expires: March 28,1994                     [Page 2]
  119.  
  120. INTERNET-DRAFT               I-NLSP                    September 23,1993
  121.  
  122. 3  I-NLSP Overview
  123.  
  124. One basic mode of operation of the I-NLSP protocol which is for use in
  125. providing a secure connectionless network service.  The connectionless
  126. network service for required by I-NLSP may be either IPV4 or CLNP and
  127. is referred to as the Datagram Forwarding Protocol (DFP). The
  128. mechanisms and functionality of I-NLSP are identical for IP and CLNP
  129. with the exception of the protected PDU format, which is different
  130. because of the unique requirements for the IP and CLNP protocols (ie.,
  131. header format and address sizes).
  132.  
  133. I-NLSP can be implemented in End Systems and in Intermediate Systems.
  134. Only those end systems and intermediate systems that require secure
  135. communications will be required to alter their existing IP or CLNP
  136. implementations.  End systems running IP and/or CLNP without I-NLSP
  137. will be able to continue communicating with other end systems and
  138. intermediate systems running IP and/or CLNP with or without I-NLSP in a
  139. non-protected fashion.  Intermediate systems with existing
  140. implementations of IP and/or CLNP will not require any changes to be
  141. able to forward datagrams protected by I-NLSP.
  142.  
  143. I-NLSP is designed so that it can be optimized to meet a range of
  144. requirements from environments where the main concern is high security
  145. to environments where the main concern is optimized performance.  The
  146. I-NLSP protocol makes use of the concept of a Security Association (SA)
  147. which is independent of the I-NLSP protocol.  A set of attributes
  148. defining parameters for security (eg algorithm, keys etc) are defined
  149. for the SA.
  150.  
  151. This protocol supports the use of a wide range of specific security
  152. mechanisms (both standardized and non-standardized).  Users and
  153. implementors should choose the security mechanisms for use with this
  154. protocol appropriate to enforce their security services and level of
  155. protection required.  The security protection which I-NLSP attempts to
  156. provide is derived from a combination of the protection requested by
  157. the I-NLSP user and the protection imposed by some security
  158. administration.
  159.  
  160. 3.1   Services provided by I-NLSP
  161.  
  162. This protocol provides the aforementioned security services by
  163. encapsulating the data and optionally the datagram header in a Secure
  164. Data Transfer (SDT) PDU. Protection mechanisms are then applied to the
  165. body of the SDT PDU. The entire SDT PDU is then forwarded to a peer
  166. entity as the data portion of DFP datagram.
  167.  
  168. On receipt of a SDT PDU, destined for this I-NLSP entity, the I-NLSP
  169. protocol parses the SDT PDU, extracts and removes the protection from
  170. the data and passes this unprotected data to the DFP for further
  171. processing.
  172.  
  173.  
  174.  
  175.  
  176.  
  177. K. R. Glenn          Expires: March 28,1994                     [Page 3]
  178.  
  179. INTERNET-DRAFT               I-NLSP                    September 23,1993
  180.  
  181. 3.2   Services assumed by I-NLSP
  182.  
  183. This protocol assumes to operate somewhere within the network layer of
  184. either the TCP/IP protocol suite or the OSI protocol suite.  Two
  185. services are assumed by the I-NLSP. The first service is access to the
  186. Security Association information.  The second service is the DFP which
  187. provides the vehicle for which protected information is forwarded.
  188.  
  189. 3.3 Security Associations 
  190.  
  191. In order to protect an instance of connectionless communication a
  192. suitable SA must exist.  A SA is a negotiated set of parameters that
  193. define the security services and levels of protection between two
  194. entities.  The SA may be established either "out-of-band" means or
  195. using an "in-band" SA Protocol (SA-P).  SA establishment, as well as a
  196. description of a SA-P, is outside the scope of this specification.
  197.  
  198. 3.4   Functional Overview
  199.  
  200. I-NLSP supports the ability to transfer protected or unprotected
  201. connectionless datagrams between peer DFP users.  I-NLSP determines
  202. locally using Quality of Service (QOS), destination address, and other
  203. management information (such as Network Management protocols and the
  204. Security Association Protocol) whether protection is needed or not.
  205.  
  206. When the DFP receives data to be forwarded (regardless of whether it
  207. came from the user of the network layer or the subnetwork), the DFP
  208. uses the I-NLSP to determine if communication is permitted with the
  209. destination address and if so whether protection is required.  If no
  210. protection is required, the data will be sent back to the DFP without
  211. change.  If protection is required, I-NLSP encapsulates the DFP
  212. datagram by use of the Encapsulation Function which:   takes an
  213. unprotected octet string, applies in order the traffic flow
  214. confidentiality, integrity and confidentiality protection mechanisms as
  215. appropriate to the protection required and returns a protected octet
  216. string.  Intermediate system functionality requires that the entire DFP
  217. datagram, including the header, be encapsulated.  In end systems
  218. encapsulating the header is optional.  The protected octet string
  219. becomes an integral part of the I-NLSP's SDT PDU. The SDT PDU then
  220. becomes the data part of a DFP datagram that is then forwarded towards
  221. the I-NLSP peer entity.
  222.  
  223. On receipt of data from a peer network layer entity, I-NLSP uses the
  224. source address and local information to determine if communication is
  225. permitted with the destination address and if so whether protection was
  226. applied.  If protection was not applied, the datagram is processed
  227. normally by the DFP.
  228.  
  229. If protection was required, the I-NLSP entity extracts the protected
  230. octet string from the SDT PDU. I-NLSP then extracts the encapsulated
  231. datagram from the protected octet string using the Decapsulation
  232. Function.  The Decapsulation Function takes a protected octet string
  233. and applies the appropriate mechanisms to remove the applied protection
  234.  
  235.  
  236. K. R. Glenn          Expires: March 28,1994                     [Page 4]
  237.  
  238. INTERNET-DRAFT               I-NLSP                    September 23,1993
  239.  
  240. and returns an unprotected octet string.  The decapsulated datagram is
  241. then processed normally by the DFP. In the case of intermediate system
  242. functionality this could result in the activation of the encapsulation
  243. process before the datagram is forwarded.  In the case of multiple
  244. encapsulations, multiple decapsulations would be required.
  245.  
  246. 3.5   Security Services and Mechanisms
  247.  
  248. This section describes the mapping between the security services
  249. provided by I-NLSP and the mechanisms used to support these services.
  250. These mechanisms are not the only mechanisms which can be used to
  251. provide security within the I-NLSP. Other mechanisms may be
  252. standardized in future and it is possible for private mechanisms to be
  253. used with I-NLSP.
  254.  
  255. I-NLSP supports the following security services, if selected, with the
  256. mechanisms described:
  257.  
  258.  1. Data Origin Authentication - the mechanism used to provide this 
  259.     service is ICVs in conjunction with key management.
  260.  
  261.  2. Access Control - the mechanisms used to provide this service are
  262.     Security Labels bound to the data and/or the control of keys 
  263.     and/or use of authenticated addresses.
  264.  
  265.  3. Connectionless Confidentiality - the mechanism used to provide this
  266.     service is encipherment.  This protection optionally includes all 
  267.     DFP header service parameters.
  268.  
  269.  4. Traffic Flow Confidentiality - the mechanism used to provide this
  270.     service is traffic padding and/or hiding the DFP-address.
  271.  
  272.  5. Connectionless Integrity the mechanism used to provide this service
  273.     is an ICV. This protection optionally includes all I-NLSP service
  274.     parameters.
  275.  
  276. The essential feature of the mechanisms supported by I-NLSP is an
  277. encapsulation/decapsulation function which supports secure data 
  278. transfer by using the following mechanisms:
  279.  
  280.  1. Padding for traffic flow confidentiality, block integrity 
  281.     algorithms, and block encipherment algorithms.
  282.  
  283.  2. Integrity Check Value.
  284.  
  285.  3. Encipherment/Decipherment.
  286.  
  287. The mechanisms are carried out in the order given above.
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295. K. R. Glenn          Expires: March 28,1994                     [Page 5]
  296.  
  297. INTERNET-DRAFT               I-NLSP                    September 23,1993
  298.  
  299. 4  Security Association Attributes
  300.  
  301. The following SA Attributes control the operation of I-NLSP and the
  302. mechanisms used to provide protection.  Their description includes 
  303. mnemonics used to refer to these attributes in this specification. 
  304. The associated values to these attributes shall be set up on SA 
  305. establishment.
  306.  
  307.  1. SA Identification:
  308.  
  309.       o My_SAID: Integer of range 0 to (256 ** maxlength) - 1
  310.         The local identifier of the SA.
  311.  
  312.  
  313.       o Your_SAID: Integer of range 0 to (256 ** maxlength) - 1
  314.         The remote identifier of the SA.
  315.  
  316.     Note that maxlength is an integer of range 2 to 126.  It is a 
  317.     serious error for there to be more than one SA with the same local
  318.     identifier.
  319.  
  320.     Editor's Note:  For all practical purposes, maxlength should be set
  321.     to no more than 5 octets.  This would provide 256**5 possible
  322.     associations.  A fixed maxlength would also eliminate the need
  323.     for the LI field of the SDT PDU.  A fixed length of 5 octets
  324.     would also resolve the problems associated with not aligning
  325.     the SDT PDU header on a word boundary.  (the header would
  326.     always be 8 octets and thus end on a word boundary).  It is
  327.     recommended that the LI field should remain and always be set to 5,
  328.     so that the ability to implement the dynamic nature intended by
  329.     this text remains.
  330.  
  331.  2. Indicator of whether the I-NLSP initiated or responded to the SA
  332.     establishment:
  333.  
  334.       o Initiator:  Boolean
  335.  
  336.     This attribute indicates how the initiator to responder flag should
  337.     be set to detect reflected PDUs.
  338.  
  339.  3. DFP Address of peer I-NLSP entity:
  340.  
  341.       o Peer_Adr:  Octet string of format specified by DFP.
  342.  
  343.  4. DFP Address of entities served through the remote peer:
  344.  
  345.       o Adr_Served:  Set of octet strings of format specified by DFP.
  346.  
  347.  5. Protection QOS selected for the SA:
  348.  
  349.       o QOS_Label:  Format defined by an Agreed Set of Security Rules 
  350.         (ASSR).
  351.  
  352.  
  353.  
  354. K. R. Glenn          Expires: March 28,1994                     [Page 6]
  355.  
  356. INTERNET-DRAFT               I-NLSP                    September 23,1993
  357.  
  358.       o DOAuth:  Integer of range defined by an ASSR defined Data Origin
  359.         Authentication level.
  360.  
  361.       o CLConf:  Integer of range defined by an ASSR defined 
  362.         Connectionless confidentiality level.
  363.  
  364.       o CLInt:  Integer of range defined by an ASSR defined 
  365.         Connectionless integrity level.
  366.  
  367.       o AC: Integer of range defined by an ASSR defined Access Control
  368.         level.
  369.  
  370.       o TF_Conf:  Integer of range defined by an ASSR defined Traffic 
  371.         Flow Confidentiality Level.
  372.  
  373.       Editor's Note:  The QOS should only be used to recommend the
  374.       levels of security service.  The actual levels are negotiated and
  375.       set by the Security Association.
  376.  
  377.  6. Parameter Protection.
  378.  
  379.       o Param_Prot:  Boolean
  380.  
  381.     Protect the I-NLSP Source address, I-NLSP Destination address, and
  382.     I-NLSP QOS parameters within the Secure Data Transfer PDU.
  383.  
  384.  7. Label mechanism attributes:
  385.  
  386.       o Label_set:  Set of
  387.           {Label_Ref:      Integer
  388.            Label_Auth:      Object Identifier
  389.            Label_Content:  Format defined by Label_Auth}
  390.  
  391.  8. Mechanism Flags selected for the SA:
  392.  
  393.       o Padd:  Boolean 
  394.  
  395.       Padding within the Protected-Octet-String to support the Traffic 
  396.       Padding mechanism.
  397.  
  398.       o ICV: Boolean 
  399.  
  400.       Integrity within a Protected-Octet-String contents using an 
  401.       integrity check value.
  402.  
  403.       o Encipher:  Boolean 
  404.       
  405.       Encipherment of a Protected-Octet-String to provide 
  406.       confidentiality.
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413. K. R. Glenn          Expires: March 28,1994                     [Page 7]
  414.  
  415. INTERNET-DRAFT               I-NLSP                    September 23,1993
  416.  
  417.  9. Padding Mechanism Attributes:
  418.  
  419.       o Traff_Padd:  Form defined by an ASSR.
  420.       
  421.       Traffic Padding requirements.
  422.  
  423. 10. ICV mechanism attributes:
  424.  
  425.       o ICV_Alg:  Object Identifier
  426.  
  427.         The value of this attribute shall be defined by an ASSR.  This 
  428.         attribute implies certain attributes of the integrity mechanism 
  429.         such as separate generate and check algorithms, initialization 
  430.         vectors, etc.
  431.  
  432.       o ICV_Blk:  Integer
  433.  
  434.         Basic block size on which the ICV algorithm operates.  The
  435.         value of this attribute shall be defined by an ASSR.
  436.  
  437.       o ICV_Len:  Integer
  438.  
  439.         The value of this attribute shall be defined by an ASSR.  The 
  440.         length of the output of the ICV mechanism.  It is not necessary 
  441.         that ICV_Len equal ICV_Blk.
  442.  
  443.       o Data_ICV_Gen_Key:  form defined by ASSR ICV generation key 
  444.         reference for data.
  445.  
  446.  
  447.       o Data_ICV_Check_Key:  form defined by ASSR ICV check key 
  448.         reference for data.
  449.  
  450.     The initial value of these "key" attributes shall be set up on SA
  451.     establishment and can be changed during the lifetime of the
  452.     association.
  453.  
  454. 11. Encipherment Mechanism Attributes:
  455.  
  456.       o Enc_Alg:  Object identifier allocated under [ISO9979].
  457.  
  458.         The value of this attribute shall be defined by the ASSR.  This
  459.         attribute implies certain attributes of the encipherment
  460.         mechanism such as the form and length of any synchronization
  461.         field, separate encipherment and decipherment algorithms,
  462.         initialization vectors, etc.
  463.  
  464.       o Enc_Blk:  Integer
  465.         Block size of encipherment algorithm.  The value of this
  466.         attribute shall be defined by the ASSR.
  467.  
  468.  
  469.       o Data_Enc_Key:  form defined by ASSR Encipherment key reference 
  470.         for data.
  471.  
  472. K. R. Glenn          Expires: March 28,1994                     [Page 8]
  473.  
  474. INTERNET-DRAFT               I-NLSP                    September 23,1993
  475.  
  476.       o Data_Dec_Key:  form defined by ASSR Decipherment key reference
  477.         for data The initial value of these "key" attributes shall be 
  478.         set up on SA establishment and can be changed during the 
  479.         lifetime of the association.
  480.  
  481.  
  482. 5  Structure and Encoding of SDT PDUs
  483.  
  484. The I-NLSP protocol uses 2 Secure Data Transfer PDU types, one for IP
  485. and one for CLNP. All SDT PDUs shall contain an integral number of
  486. octets.  The octets in a PDU are numbered starting from one (1) and
  487. increasing in the order in which they are sent and received.  When
  488. consecutive octets are used to represent a binary number, the lower
  489. octet number has the most significant value.  The bits in an octet are
  490. numbered from one (1) to eight (8), where bit one (1) is the low-order
  491. bit.
  492.  
  493. When the encoding of a PDU is represented using a diagram in this
  494. section; Octets are shown with the lowest numbered octet to the left or
  495. above; and within an octet, bits are shown with bit eight (8) to the
  496. left and bit (1) to the right.  The notations below a box show the
  497. length of each field in octets; "var" indicates that the field length
  498. is variable.
  499.  
  500. The presence or absence of an "optional" field shall be specified by
  501. the attributes contained in the Security Association.  Note: The
  502. optional fields are optional in that a given security association will
  503. require the presence of certain fields and the absence of other
  504. fields.  Once the Security Association is decided, the presence or
  505. absence of each field is determined by the SA Attributes.
  506.  
  507. 5.1   Secure Data Transfer PDU
  508.  
  509. The format of a Secure Data Transfer PDU shall be as shown in Figure 1.
  510.  
  511.  
  512.  
  513.           +-----------------------------------------------+
  514.           |  Unprotected Header |  Protected-Octet-String |
  515.           +-----------------------------------------------+
  516.  
  517.  
  518.              Figure 1:  Secure Data Transfer PDU Structure
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531. K. R. Glenn          Expires: March 28,1994                     [Page 9]
  532.  
  533. INTERNET-DRAFT               I-NLSP                    September 23,1993
  534.  
  535. 5.1.1   Unprotected Header
  536.  
  537. The format of the Unprotected Header shall be as shown in Figure 2.
  538.  
  539.  
  540.                 +---------------------------------------+
  541.                 | Protocol | Length    |  PDU  |  SAID  |
  542.                 |   ID     | Indicator |  Type |        |
  543.                 +---------------------------------------+
  544.                     1           1          1       var
  545.  
  546.  
  547.                       Figure 2:  Unprotected Header
  548.  
  549.  
  550.  1. Protocol Id - This field shall contain the I-NLSP protocol 
  551.     identifier, value 01000101.
  552.  
  553.     Editor's Note:  As long as I-NLSP and NLSP remain functionally 
  554.     aligned, the PIDs can be the same.  Once the functionality 
  555.     diverges a new PID needs to be determined.
  556.  
  557.  2. Length Indicator - This field contains the length of the PDU Type 
  558.     field plus the SAID.
  559.  
  560.  3. PDU Type - This field shall contain the PDU type value of 01001000 
  561.     or 01001010 to indicate a Secure Data Transfer PDU for CLNP or IP
  562.     respectively.
  563.  
  564.  4. SAID - The SAID field shall contain the Security Association 
  565.     Identifier of the remote entity (that is, the SA attribute 
  566.     Your_SAID).
  567.  
  568.     Editor's Note:  A fixed SAID length would also eliminate the need
  569.     for the LI field of the SDT PDU.  It is recommended that the LI
  570.     exist and always be set to 5, so that the possibility of
  571.     implementing the dynamic nature intended by this text remains.
  572.  
  573. 5.1.2   Protected-Octet-String
  574.  
  575. The Protected-Octet-String field shall contain the output from an
  576. Encapsulate Function.  The structure of the Protected-Octet-String is
  577. dependent on the specific mechanisms used and is shown in Figure 3.
  578. The Integrity Mechanism is applied to the Unprotected-Octet-String.
  579. The Encipherment Mechanism is applied to the entire
  580. Protected-Octet-String.
  581.  
  582.  
  583.                +--------------------------------------------+
  584.                | Crypto  | Unprotected-Octet  |  ICV  | Enc |
  585.                |  Sync   |       String       |       | Pad |
  586.                +--------------------------------------------+
  587.  
  588.                        Figure 3:  Protected-Octet-String
  589.  
  590. K. R. Glenn          Expires: March 28,1994                    [Page 10]
  591.  
  592. INTERNET-DRAFT               I-NLSP                    September 23,1993
  593.  
  594.  1. Crypto Synchronization: This is an optional field which may 
  595.     contain Synchronization data for specific encipherment algorithms.  
  596.     Its presence, form, and length are implied by Enc_Alg.
  597.  
  598.  2. Unprotected-Octet-String: Figure 4 shows the format for the
  599.     Unprotected-Octet-String. The encoding of the
  600.     Unprotected-Octet-String shall be a two octet length of the entire
  601.     Unprotected-Octet-String, followed by one octet, (Data Type) then a
  602.     series of TLV encoded Content Fields.  The structure of the
  603.     Unprotected-Octet-String is described in more detail in the
  604.     following section.
  605.  
  606.  3. Integrity Check Value (ICV): This field contains an Integrity Check
  607.     Value (ICV). The length of this field shall be defined by the ICV
  608.     Length contained in the Security Association attributes.
  609.  
  610.  4. Encipherment Pad: This field contains padding for the purposes of
  611.     supporting block encipherment algorithms for confidentiality.  The
  612.     choice of padding value is a local matter.  All I-NLSPEs must be
  613.     able to discard this field.  The format of this field shall be
  614.     defined in section 5.1.3.  The Type code of this TLV field shall be
  615.     as defined in section 5.1.3.  If a two octet pad is required the
  616.     length shall be zero with no value.  If a single octet pad is
  617.     required a single octet PAD field shall be used instead of an
  618.     Encipherment PAD field.
  619.  
  620. 5.1.3   Content Fields
  621.  
  622. There are two types of Content Fields, Mechanism-Independent
  623. (MI-Content) which contain the data to be protected, and
  624. Mechanism-Dependent (MD-Content) which contains information required by
  625. the security mechanisms.
  626.  
  627. The Content Length and at least one MI-Content Field are required.
  628.  
  629.  
  630.      +--------------------------------------------------------------+
  631.      |  Content  |  Data  |  MI-Content  |  ... | MD-Content |  ... |
  632.      |  Length   |  Type  |    Field     |      |   Field    |      |
  633.      +--------------------------------------------------------------+
  634.             2          1        var                   var  
  635.  
  636.  
  637.                    Figure 4:  Unprotected-Octet-String
  638.  
  639.  
  640.  1. Content Length
  641.  
  642.     This field shall contain the length of the PDU contents from the 
  643.     Data Type field up to the end of the last MD-Content Field.
  644.  
  645.  
  646.  
  647.  
  648.  
  649. K. R. Glenn          Expires: March 28,1994                    [Page 11]
  650.  
  651. INTERNET-DRAFT               I-NLSP                    September 23,1993
  652.  
  653.  2. Data Type 
  654.  
  655.     Bit 8 of this fields shall be the "Initiator to Responder" flag.  A
  656.     value of 1 indicates Initiator to Responder.  A value of 0
  657.     indicates Responder to Initiator.  Bits 1-7 of this field are
  658.     0000001.
  659.  
  660.     Editor's Note: The existence of this field in [ISO11577] was to
  661.     relay two items of information.  The first, located in bit 8, was
  662.     which peer entity initiated the SA.  It is not clear as to what
  663.     type of threat this is designed to protect against.  The second was
  664.     used to identify between Connectionless and Connection-Oriented
  665.     types of data.  It is recommended that this field could contain
  666.     information pertaining to the locations and sizes of the Content
  667.     Fields.  This would eliminate most of the TLV problems associated 
  668.     with this protocol.  An example would be:
  669.  
  670.     Value                    Meaning
  671.     -----                   -------
  672.     x000 0001              connectionless Data with TLV encoding
  673.     x000 0010 - x000 0111  reserved for Connection Oriented Protocol
  674.     x000 1000              connectionless Data with fixed positions, 
  675.                            variable lengths.
  676.     x000 1001              connectionless Data with fixed positions 
  677.                            and fixed lengths.
  678.  
  679.  3. Content Field Format 
  680.  
  681.     The Content Field is a general field format for data values 
  682.     to be placed in the SDT PDUs.  Both types of Content Fields are 
  683.     Type-Length-Value Encoded as shown in Figure 5.
  684.  
  685.  
  686.                   +---------------------------+
  687.                   |  Type  | Length  | Value  |
  688.                   +---------------------------+
  689.                       1        1-3        var
  690.  
  691.  
  692.                      Figure 5:  Content Field
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708. K. R. Glenn          Expires: March 28,1994                    [Page 12]
  709.  
  710. INTERNET-DRAFT               I-NLSP                    September 23,1993
  711.  
  712.     (a)  Type - The MI-Content Field Type shall be set to one of 
  713.          the following values:
  714.  
  715.         Value           MI-Content Field Type
  716.         ---------       ---------------------
  717.         1100 0000       Userdata
  718.         1100 0010       Source DFP Address
  719.         1100 0011       Destination DFP Address
  720.         1100 0101       QOS
  721.         1100 0110       Label
  722.         1100 0111       Label Reference
  723.  
  724.     Editor's Note:  An additional MI-Content Field Type may be
  725.     required to represent a DFP datagram with DFP header.
  726.  
  727.     The MD-Content Field Type Shall be set to one of the following
  728.     values:
  729.  
  730.         Value           MD-Content Field Type
  731.         ---------       ---------------------
  732.         1101 0001       Single Octet Pad
  733.         1101 0010       Traffic Pad
  734.         1101 0011       Integrity Pad
  735.         1101 0100       Reserved (See Encipherment Pad)
  736.  
  737.    (b)  Length - The Content Field Length shall contain the length of 
  738.         the Content Field Value in octets.  The Content Field Length 
  739.         shall be one, two or three octets long.
  740.  
  741.         i. If one octet long then bit 8 shall be 0 and the remaining 7 
  742.            bits define a value length up to 127 octets.
  743.  
  744.        ii. If two octets long then the first octet shall be encoded as
  745.            1000 0001 and the remaining octet defines the fields length 
  746.            up to 255 octets.
  747.  
  748.       iii. If three octets long then the first octet shall be encoded 
  749.            as 1000 0010 and the remaining two octets define the field 
  750.            length up to 65,535 octets.  Other values of the first octet 
  751.            are reserved for future use.
  752.  
  753.       Editor's Note:  The processing requirements needed to parse this
  754.       type of TLV encoding are extreme.  It is recommended that the
  755.       Length field be altered to be fixed in size depending on the type
  756.       of the Content Field.
  757.  
  758.    (c)  MI-Content Field Values
  759.  
  760.         i. Userdata - This field contains the DFP Data.  
  761.         
  762.         Editor's Note: Optionally this field can contain the DFP 
  763.         datagram header.
  764.  
  765.  
  766.  
  767. K. R. Glenn          Expires: March 28,1994                    [Page 13]
  768.  
  769. INTERNET-DRAFT               I-NLSP                    September 23,1993
  770.  
  771.         Editor's Note:  The fixed Length size, as recommended above,  
  772.         for this field would be 2 Octets (a Length value of 1 to 
  773.         65,536).
  774.     
  775.        ii. Source DFP Address - This field contains a DFP address.  
  776.            Depending on the PDU Type this field is either a Network 
  777.            Layer address encoded in one of the forms described in 
  778.            [ISO8348Ad2] or a fixed length 4 octet IP address.
  779.  
  780.         Editor's Note:  The fixed Length size for this field, as 
  781.         recommended above, would be 1 Octet.
  782.  
  783.       iii. Destination DFP Address - This field contains a DFP
  784.            address.  Depending on the PDU Type this field is either a 
  785.            Network Layer address encoded in one of the forms described 
  786.            in [ISO8348Ad2] or a fixed length 4 octet IP address.
  787.  
  788.         Editor's Note:  The fixed Length size for this field, as
  789.         recommended above, would be 1 Octet.
  790.  
  791.        iv. I-NLSP Security QOS - This field shall be used to carry the 
  792.            I-NLSP QOS parameter set.  This field shall contain a 
  793.            sequence of octets indicating the levels of protection QOS 
  794.            required in terms of security services.  The semantics of 
  795.            the levels is defined as part of the security policy.  The 
  796.            octets for each of the security services shall appear in 
  797.            the order indicated below.  The sequence of octets can be 
  798.            truncated if the truncated octets all relate to the services
  799.            that have the QOS value 0.  A single octet of value 255 shall
  800.            indicate that protection QOS requirements have been 
  801.            pre-established.
  802.  
  803.            Octet   Meaning
  804.            1        Connectionless Confidentiality
  805.            2        Connectionless Integrity
  806.            3        Data Origin Authentication
  807.            4        Access Control
  808.            5        Traffic Flow Confidentiality
  809.  
  810.         Editor's Note:  The fixed Length size for this field, as 
  811.         recommended above, would be 1 Octet.
  812.  
  813.         v. Label - This field shall be used to carry the security label 
  814.            of a PDU. This field is not present if a Label Reference 
  815.            Content field is present.
  816.  
  817.               +-----------------------------------------------+
  818.               | Authority  | Defining    |  Label  | Label    |
  819.               |  Length    |  Authority  |  Length | Content  |
  820.               +-----------------------------------------------+
  821.  
  822.  
  823.                           Figure 6:  Label Value
  824.  
  825.  
  826. K. R. Glenn          Expires: March 28,1994                    [Page 14]
  827.  
  828. INTERNET-DRAFT               I-NLSP                    September 23,1993
  829.  
  830.           The structure and interpretation of the Contents of the
  831.           Label are defined by various Defining Authorities.
  832.  
  833.         Editor's Note:  The fixed Length size for this field, as
  834.         recommended above, would be 2 Octets.
  835.  
  836.        vi. Label Reference - This field identifies one of the set of 
  837.            security labels defined in the SA attribute Label_Set.  This
  838.            field shall always be encoded so that the value part of the
  839.            field is two octets.  This field shall not be present if a
  840.            Label Content field is present.
  841.  
  842.         Editor's Note:  The fixed Length size for this field, as 
  843.         recommended above, would be 1 Octet.
  844.  
  845.    (d)  MD-Content Field Values
  846.         i. Single Octet Pad - This field shall be a 1 octet  (type 
  847.            without Length or Value) field for general padding (for 
  848.            example, to support a single octet of integrity padding).  
  849.            This octet may be used instead of a TLV encoded Integrity, 
  850.            Encipherment, or Traffic Pad field to provide integrity, 
  851.            encipherment, or traffic padding.  All I-NLSPEs shall detect
  852.            and discard this field.
  853.  
  854.        ii. Traffic Pad - This field contains padding for the purposes 
  855.            of traffic flow confidentiality.  The choice of padding 
  856.            value is a local matter.  All I-NLSPEs shall detect and 
  857.            discard this field.  If a two octet pad is required the 
  858.            length shall be zero with no value.  If a single octet pad 
  859.            is required a Single Octet Pad shall be used instead of a 
  860.            Traffic Pad.
  861.  
  862.       iii. Integrity Pad - This field contains padding for the purposes 
  863.            of supporting block integrity algorithms.  The choice of 
  864.            padding value is a local matter.  All I-NLSPEs must be able 
  865.            to discard this field.  If a two octet pad is required the 
  866.            length shall be zero with no value.  If a single octet pad is 
  867.            required a Single Octet Pad shall be used instead of an 
  868.            Integrity Pad.
  869.  
  870.  
  871. 6  I-NLSP Protocol Functionality
  872.  
  873. This section describes the protocol utility functions for I-NLSP.
  874.  
  875. 6.1    Using QOS to determine Security Policy
  876.  
  877. The following QOS security sub-parameters are modifications to any
  878. existing Quality of Service security parameters.  Table (a) identifies
  879. the placement of these parameters depending on whether data is to be
  880. encapsulated or decapsulated.  Within the QOS parameter protection may
  881. be specified by either explicitly stating the following protection QOS
  882. sub-parameters indicating the level of protection for each service
  883.  
  884.  
  885. K. R. Glenn          Expires: March 28,1994                    [Page 15]
  886.  
  887. INTERNET-DRAFT               I-NLSP                    September 23,1993
  888.  
  889. requested or explicitly stating a security label which implies
  890. protection requirements.
  891.  
  892.  1. Data Origin Authentication
  893.  2. Access Control
  894.  3. Connectionless Confidentiality
  895.  4. Traffic Flow Confidentiality
  896.  5. Connectionless Integrity
  897.  
  898.  
  899. Table a  --  Security Quality of Service Parameters
  900.  
  901. Security Quality of Service      Encapsulated   Decapsulated
  902. ---------------------------      ------------   ------------
  903. Data Origin Authentication             X             X
  904. Access Control                         X             X
  905. Connectionless Confidentiality         X             X
  906. Traffic Flow Confidentiality           X             X
  907. Connectionless Integrity               X             X
  908. Security Label                         X             X(=)
  909.  
  910. Note 1:  In this table X indicates QOS parameter may be present; (=)
  911. indicates that Indication parameter must be the same as the Request
  912. parameter.  Note 2:  It is possible for an administratively imposed
  913. security policy to be enforced by the I-NLSPE, in which case the policy
  914. may dictate a level and type of security protection which is not
  915. identical to that requested by the DFP user.  However the security
  916. label is a sensitivity indication and its value will be that given by
  917. the user or his agent and will not be changed by the I-NLSPE.
  918.  
  919. Editor's Note:  It is recommended that the Security QOS be used in the
  920. Security Association negotiations, but not in the decision for the
  921. actual security mechanisms applied to the data.
  922.  
  923. 6.2   Checks
  924.  
  925. At many points in the following descriptions, the I-NLSP entity checks
  926. that some condition is satisfied.  Unless otherwise specified, whenever
  927. such a check fails, the I-NLSP entity shall discard the data currently
  928. being processed.  Optionally, the entity may also file an audit
  929. report.  What failures are to be audited is considered to be a local
  930. matter.
  931.  
  932. 6.3   Identification of the Security Association
  933.  
  934. An I-NLSPE receiving a request for an instance of communication
  935. identifies among the SAs available to it an SA whose attributes satisfy
  936. the following conditions:
  937.  
  938.  1. If the I-NLSP Protection QOS is specified then this Protection Set
  939.     equals the following SA attributes:  QOS_Label, DOAuth, AC,
  940.     CLConf, TF_Conf, and or CLInt.
  941.  
  942.  
  943.  
  944. K. R. Glenn          Expires: March 28,1994                    [Page 16]
  945.  
  946. INTERNET-DRAFT               I-NLSP                    September 23,1993
  947.  
  948.  2. The I-NLSP Destination Address is contained within the set of DFP
  949.     addresses in Adr_Served.  The procedure to be followed if more than
  950.     one SA satisfies these conditions is a local matter.  If no such SA
  951.     exists and if "in band" SA establishment is supported then the
  952.     Security Association Protocol (SA-P), option may be selected.  An
  953.     SA may be established "in band" using a SA-P. Otherwise
  954.     "out-of-band" SA establishment procedures may be followed.  If
  955.     neither of these procedures cannot be completed successfully within
  956.     a locally defined timeout then error recovery procedures as defined
  957.     in section 6.2 will be carried out.
  958.  
  959. 6.4   Use of a Security Association Protocol
  960.  
  961. When two I-NLSPEs do not have an SA established, they may establish an
  962. SA by notifying a Security Association Protocol (SA-P) or some other
  963. method.  A SA-P will then optionally perform the necessary steps to
  964. establish, modify, or terminate a SA. An SA-P may be based on either
  965. symmetric or asymmetric algorithms.   The SA-P is a separate protocol,
  966. typically at the application layer, used to provide security attribute
  967. management.  The SA-P is mentioned within this document so that the
  968. relationship between the SA-P and I-NLSP is better understood.
  969.  
  970. Editor's Note:  It is recommended that the Security QOS be used by the
  971. SA-P to help establish or modify a SA.
  972.  
  973. 6.5    Initial Checks
  974.  
  975. An I-NLSP entity (I-NLSPE) receiving a request for an instance of
  976. communication shall check that:
  977.  
  978.  1. The I-NLSP Source Address is an DFP address served by this I-NLSPE
  979.     as determined by local security policy.
  980.  
  981.  2. The I-NLSP security label or protection QOS is within the set of 
  982.     labels or protection QOS that can be processed by this I-NLSPE as 
  983.     determined by local security policy.
  984.  
  985.  3. If unprotected instances of communication are allowed to the I-NLSP
  986.     Destination Address and the I-NLSP Protection QOS parameter does not
  987.     indicate any protection requirements then I-NLSP shall allow the DFP
  988.     to forward the datagram without change.
  989.  
  990. 6.6   Processing a DFP request for Encapsulation
  991.  
  992. Once it has been determined that Encapsulation is required and a SA
  993. exists for this instance of communication, a SDT PDU shall be
  994. generated.
  995.  
  996.  
  997. 6.6.1   Generate Secure Data Transfer PDU
  998.  
  999. The following procedures shall be formed when generating a Secure Data
  1000. Transfer PDU:
  1001.  
  1002.  
  1003. K. R. Glenn          Expires: March 28,1994                    [Page 17]
  1004.  
  1005. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1006.  
  1007.  1. The Data Type Field bit 8 shall be set to the Initiator value 
  1008.     contained in the SA.
  1009.  
  1010.  2. The Data Type Field bits 1-7 are set to the value defined in 5.1.3.
  1011.  
  1012.  3. If (Param_Prot is TRUE) then at least
  1013.     one of the following shall be performed depending on local security
  1014.     policy:
  1015.  
  1016.    (a)  Place the source DFP address in the Source Address Content Field 
  1017.         as defined in 5.1.3.
  1018.  
  1019.    (b)  Place the destination DFP address in the Destination Address 
  1020.         Content Field as defined in 5.1.3.
  1021.  
  1022.    (c)  Place the I-NLSP QOS parameter set in the QOS Parameter Content 
  1023.         Field as defined in 5.1.3.
  1024.  
  1025.  4. Place the DFP Userdata in the User Data Content Field as defined in
  1026.     5.1.3.  The DFP header is also included in this field if either
  1027.     this or the peer I-NLSPE is operating as an IS or optionally
  1028.     otherwise. 
  1029.     
  1030.     Editor's Note: Another SDT PDU field may be required to determine
  1031.     whether the DFP header is included.  The DFP existing header is
  1032.     necessary for forwarding after running the I-NLSP decapsulate
  1033.     function. Information other than Source address, Destination
  1034.     address and QOS are required for further processing (ie.,
  1035.     segmentation and reassembly information).  This could easily be
  1036.     implemented using another MI-Content Field Type.
  1037.  
  1038.     Editor's Note: It is unclear that if the DFP header is included in
  1039.     the Userdata Content field that the other fields are necessary.  It
  1040.     is equally unclear that if the I-NLSP QOS is only to be used by the
  1041.     SA-P, why should it be transmitted as part of an SDT PDU.
  1042.  
  1043.  5. If (Label is TRUE) then either:
  1044.  
  1045.    (a)  a security label, shall be placed in a Label Content Field and
  1046.         included in the PDU, or
  1047.  
  1048.    (b)  a security label reference, shall be placed in a Label Reference
  1049.         Content Field and and included in the PDU.
  1050.  
  1051.  6. The Encapsulation function shall be called with the following 
  1052.     arguments being passed:
  1053.  
  1054.    (a)  SAID shall be set to My_SAID.
  1055.    (b)  unprotected-octet-string shall be set to the constructed PDU 
  1056.         fields.
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062. K. R. Glenn          Expires: March 28,1994                    [Page 18]
  1063.  
  1064. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1065.  
  1066.  7. The Encapsulation function shall return either an error or a
  1067.     Protected-Octet-String.  Upon successful completion of the 
  1068.     Encapsulate function the following processing shall be performed to 
  1069.     create an Unprotected Header for the SDT PDU.
  1070.  
  1071.  8. The Protocol ID field shall be set to the value defined in 5.1.1.
  1072.  
  1073.  9. The LI field shall be set to the value of 1 + the length of 
  1074.     Your_SAID as defined in 5.1.1 and appended to the Protocol ID field.
  1075.  
  1076. 10. The PDU Type field shall be set to the value defined in 5.1.1 and
  1077.     appended to the LI field.
  1078.  
  1079. 11. The SAID field as defined in 5.1.1 shall be set to the value in
  1080.     Your_SAID and appended to the PDU Type field.
  1081.  
  1082. 12. The protected-octet-string shall be appended to the SAID field.
  1083.  
  1084. 13. The data parameter shall be set to equal the SDT PDU constructed by 
  1085.     the above.  Upon successful completion of the Encapsulate function 
  1086.     the data parameter shall be set to equal the protected-octet string.
  1087.  
  1088. 6.6.2   Encapsulation Function
  1089.  
  1090. This section defines an Encapsulation function.  This Encapsulation
  1091. function is based on three functions:  Padding, ICV, and Encipherment.
  1092. The decision to employ a particular function shall be based on
  1093. attributes of the SA. If traffic padding is selected, a traffic padding
  1094. field may be added.  If a block integrity algorithm is used, an
  1095. integrity padding field may be added.
  1096.  
  1097. If integrity checking is selected, an ICV shall be computed over and
  1098. appended to the above fields.  If a block encipherment algorithm shall
  1099. be used, an encipherment padding field may be added.  If encipherment
  1100. is selected, the above fields are enciphered using the encipherment key
  1101. for the Security Association.  The procedure described above
  1102. encapsulates user data and other I-NLSP protocol parameters to provide
  1103. protection for transfer over a network.  At the remote end, the
  1104. recipient of a Secure Data Transfer PDU removes and checks protection
  1105. by reversing the procedure order.
  1106.  
  1107. Editor's Note:  To simplify this protocol it is recommended that only
  1108. one pad field be used for all padding functionality.
  1109.  
  1110. 6.6.2.1 Procedures  
  1111.  
  1112. As encapsulation takes place, a PDU shall be formed by appending or
  1113. pre-pending fields.  These fields may be optional.  A partially formed
  1114. PDU is referred to be low as "existing fields".  During decapsulation a
  1115. PDU shall be decomposed by removing fields.  A partially decomposed PDU
  1116. is referred to below as "remaining data".  Note:  The description of
  1117. appending and pre-pending fields is not meant to constrain
  1118. implementations of I-NLSP but rather to unambiguously specify the
  1119. protocol.
  1120.  
  1121. K. R. Glenn          Expires: March 28,1994                    [Page 19]
  1122.  
  1123. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1124.  
  1125. 6.6.2.2 Functionality  
  1126.  
  1127. The SAID shall be used to reference a Security Association.  If the 
  1128. Security Association does not exist then the error SA-not-available
  1129. shall be returned and the value of protected-octet-string shall be
  1130. undetermined.
  1131.  
  1132. The unprotected-octet-string shall be placed in an
  1133. Unprotected-Octet-String Field.  The Unprotected Octet String Length
  1134. field shall be pre-pended and its value shall be made equal to the
  1135. length of the Unprotected Octet String.  If (Padd is TRUE) then an
  1136. amount and form of padding as determined locally by the ASSR rules
  1137. referred to in Traffic_Padd shall be placed in a Traffic Padding
  1138. Content Field and appended to the existing fields.  If a single octet
  1139. of padding is required, then the Single Octet Padding Content Field
  1140. shall be used.
  1141.  
  1142. A Content Length shall be pre-pended to the existing fields.  The
  1143. length of all existing fields shall be determined and placed in the
  1144. Content Length.
  1145.  
  1146. If (ICV is TRUE) and (ICV_Blk >1) then, if necessary, an Integrity Pad
  1147. field shall be appended to the existing fields such that the length of
  1148. the existing fields with the Integrity Pad field (including the
  1149. protected content field) is an integral multiple of the ICV block size
  1150. (that is, ICV_Blk).  If present, then an amount and form of padding as
  1151. determined by local security policy shall be placed in the Integrity
  1152. Pad Content Field.  If a single octet of padding is required, then the
  1153. Single Octet Pad Content Field shall be used.  The Content Length value
  1154. shall be increased by the amount of padding added.
  1155.  
  1156. If (ICV is TRUE) then an ICV of length ICV_Len shall be calculated
  1157. over, and appended to, the existing fields.  The algorithm used shall
  1158. be identified by ICV_Alg and the key used shall be the
  1159. Data_ICV_Gen_Key.
  1160.  
  1161. If (Encipher is TRUE) then a crypto synchronization Field with a form
  1162. and length as determined by the Alg_Id shall be generated and
  1163. pre-pended to the existing fields.  If (Encipher is TRUE) then an
  1164. encipherment pad shall be appended to the existing fields so that the
  1165. length of the existing fields (that is, Protected Data Length,
  1166. Unprotected-Octet-String, Integrity Pad, and ICV fields) plus the
  1167. length of an encipherment pad shall be an integral multiple of the
  1168. encipherment block size (that is, Enc_Blk).  If present, then the
  1169. amount and form of padding as determined by local security policy shall
  1170. be placed in an Encipherment Pad Content Field.  If a single octet of
  1171. padding is required, the Single Octet Padding Content Field shall be
  1172. used.
  1173.  
  1174. If (Encipher is TRUE) then the existing fields are enciphered.  The
  1175. algorithm used shall be identified by Enc_Alg and the key used shall be
  1176. either the Data_Enc_Key The constructed PDU shall be returned as the
  1177. result in protected-octet-string.
  1178.  
  1179.  
  1180. K. R. Glenn          Expires: March 28,1994                    [Page 20]
  1181.  
  1182. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1183.  
  1184. 6.6.3   Sub-Network Request
  1185.  
  1186. The SDT PDU shall be encapsulated as a DFP datagram and forwarded by
  1187. the DFP to the peer I-NLSPE. The DFP datagram Source Address shall be
  1188. the DFP-address of this I-NLSPE. The content of non-security relevant
  1189. QOS parameters shall be determined by local policy but may be obtained
  1190. from the I-NLSP QOS. The DFP datagram Destination Address shall be set
  1191. to the DFP-address of the peer I-NLSPE. Note: If record route and
  1192. source route parameters are in I-NLSP QOS parameters and are not passed
  1193. as QOS parameters, then the specified QOS may not be provided for the
  1194. part of the route between source and destination I-NLSP entities.
  1195.  
  1196. 6.7   SDT PDU/DFP Encapsulate Request Relationships
  1197.  
  1198. Figure 7 shows how the SDT PDU encodings described above are derived 
  1199. and how they relate to each other when processing a DFP Request for 
  1200. encapsulation.
  1201.  
  1202. 6.8   Processing a DFP request for Decapsulation
  1203.  
  1204. In addition to the initialize checks performed for any instance of
  1205. communication the following checks are also performed.
  1206.  
  1207. 6.8.1    Destination Address Check
  1208.  
  1209. The I-NLSP shall check that the DFP Destination Address is a DFP-address 
  1210. served by this I-NLSP entity.  
  1211.  
  1212. 6.8.2    Check Received Secure Data Transfer PDU
  1213.  
  1214. The following procedures shall be formed when parsing a Secure Data 
  1215. Transfer PDU:
  1216.  
  1217.  1. The I-NLSPE shall identify among the SAs available to it an SA with
  1218.     My_SAID equal to the SAID Field in the received PDU. All further
  1219.     operations refer to this identified SA.
  1220.  
  1221.     If Param_prot is TRUE then the I-NLSPE shall set the actual DFP
  1222.     addresses to the values contained in the SDT PDU. Otherwise the
  1223.     addresses contained in the DFP header will be used.  The I-NLSP
  1224.     entity shall check that the DFP Source Address is the address of an
  1225.     DFP User entity reachable via the peer I-NLSP entity.
  1226.  
  1227.     If Param_prot is TRUE, then the actual protection QOS shall be
  1228.     derived from the Protected Octet String of the SDT PDU. Otherwise
  1229.     any protection QOS contained in the DFP datagram header will be
  1230.     used.
  1231.  
  1232.  2. The Unprotected Header shall be discarded from the PDU.
  1233.  
  1234.  3. The Decapsulate Function shall be called with the following 
  1235.     arguments being passed:
  1236.  
  1237.  
  1238.  
  1239. K. R. Glenn          Expires: March 28,1994                    [Page 21]
  1240.  
  1241. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1242.  
  1243.    (a)  SAID shall be set to My_SAID
  1244.    (b)  protected-octet-string shall be set to the remainder of the PDU.
  1245.  
  1246.  4. The Decapsulate function shall return either an error or an
  1247.     unprotected-octet-string.  Upon successful completion of the 
  1248.     Decapsulate function the following processing shall be performed.
  1249.  
  1250.  5. The Data Type Field, bit 8 (Initiator to Responder) flag shall be
  1251.     checked to NOT equal the value of Initiator in the SA.
  1252.  
  1253.  6. Data Type Field, bits 1-7 shall be checked to be a value defined in
  1254.     5.1.3.
  1255.  
  1256.  7. If (Label is TRUE) then the PDU shall be checked to ensure that one
  1257.     and only one Label or Label Reference Content Field is present; else
  1258.     the remaining data shall be checked to ensure that no Label or
  1259.     Label Reference Content Field is present.  If present, the value of
  1260.     the label shall be checked to ensure it is contained in the set
  1261.     Label_Set.
  1262.  
  1263.  8. If (Param_Prot is TRUE) the PDU shall be checked to ensure that at 
  1264.     least one of the following fields is present:
  1265.  
  1266.    (a)  Destination Address.
  1267.    (b)  Source Address.
  1268.    (c)  QOS.
  1269.  
  1270.  9. The PDU shall be checked to ensure that, at most, one Destination
  1271.     Address Content Field is present.  If present, the value shall be
  1272.     checked to ensure that it is an DFP address served by this I-NLSPE
  1273.     as determined by local security policy.
  1274.  
  1275. 10. The PDU shall be checked to ensure that, at most, one Source Address
  1276.     Content Field is present.  If present, the value shall be checked to
  1277.     ensure that it is an DFP address contained in Adr_Served.
  1278.  
  1279. 11. The PDU shall be checked to ensure that, at most, one QOS Parameter 
  1280.     Content Field is present.  If present, the Protection QOS values 
  1281.     within this field shall be checked to ensure they equal the 
  1282.     following SA attributes:  QOS_Label, DOAuth, AC, CLConf, TF_Conf, 
  1283.     and CLInt.
  1284.  
  1285. 12. If (Param_Prot is FALSE) the PDU shall be checked to ensure that no 
  1286.     Destination, Source, or QOS Parameter Content Fields are present.
  1287.  
  1288. 13. The PDU shall be checked to ensure that, at most, one Data Content 
  1289.     Field is present; else the PDU shall be checked to ensure that a 
  1290.     Data Content Field is not present.  
  1291.  
  1292. 6.8.3   Decapsulate Function
  1293.  
  1294. If any of the following checks fail all security relevant status
  1295. information will be set to the security status information before
  1296.  
  1297.  
  1298. K. R. Glenn          Expires: March 28,1994                    [Page 22]
  1299.  
  1300. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1301.  
  1302. reception of this message, except for alarm, auditing, and/or
  1303. accounting information.  The SAID argument shall be used to reference a
  1304. Security Association.  If the Security Association does not exist then
  1305. the error SA-not-available shall be returned and the value of
  1306. unprotected-octet-string shall be undetermined.  If (Encipher is TRUE)
  1307. then the following steps are taken:
  1308.  
  1309. a) The protected-octet-string shall be decrypted.  The decipherment 
  1310.    algorithm used shall be identified by Enc_Alg and the key used shall 
  1311.    be the Data_Dec_Key.
  1312. b) The Crypto Synchronization field shall be removed by discarding a 
  1313.    number of octets, as determined by the Enc_Alg, from the front of the
  1314.    deciphered data.  
  1315. c) The Encipherment Pad or Single Octet Pad Content Field shall be
  1316.    removed by adding the Contents Length and ICV_Len then discarding any
  1317.    octets in the remaining deciphered data which are beyond the 
  1318.    calculated length.
  1319.  
  1320. If (ICV is TRUE) then the following steps are taken:
  1321.  
  1322. a) The ICV field shall be verified by checking the last ICV_Len octets
  1323.    of the remaining data.  The algorithm used shall be identified by
  1324.    ICV_Alg and, if cryptographically based, the key used to calculate
  1325.    the ICV shall be the Data_ICV_Check_Key.
  1326. b) If the ICV verification fails, then the error
  1327.    data-unit-integrity-failure shall be returned and the value of 
  1328.    unprotected-octet-string shall be undetermined.  The ICV shall be 
  1329.    removed by discarding any octets in the remaining data which are
  1330.    beyond the length contained in Content Length + 2.  Content fields
  1331.    that the decapsulate function does not recognize are ignored.
  1332.  
  1333. The Content Length field shall be removed by discarding the first two
  1334. octets of the remaining data.  Any Traffic Padding, Integrity Padding,
  1335. or Single Octet Padding Content Fields are removed from the remaining
  1336. data by removing data beyond the Unprotected Octet String.  Note: The
  1337. Content Fields are located by decoding the contents of the Unprotected
  1338. Octet String, which is a one-octet Type field followed by a number of
  1339. TLV fields.  The value of the Unprotected-Octet-String shall be
  1340. returned as the result in unprotected-octet-string.
  1341.  
  1342. Data from the unprotected-octet-string is extracted and sent to the DFP
  1343. for further processing.  This could result in:  Passing the data to the
  1344. user of the DFP; Forwarding the data toward the protected destination
  1345. (possibly re-encapsulating the datagram); or being passed back to
  1346. I-NLSP for additional decapsulation.
  1347.  
  1348. 6.8.4    SDT PDU/DFP Decapsulate Request Relationships
  1349.  
  1350. Figure 8 shows how the SDT PDU encodings described above are derived 
  1351. and how they relate to each other when processing a DFP Request for
  1352. decapsulation.
  1353.  
  1354.  
  1355.  
  1356.  
  1357. K. R. Glenn          Expires: March 28,1994                    [Page 23]
  1358.  
  1359. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1360.  
  1361.  
  1362.                 +-------------------------------------+
  1363.                 |  DFP Header |        User Data      |
  1364.                 +-------------------------------------+
  1365.                               |
  1366.                               |   Generate MI-Content Fields
  1367.                               V
  1368.  
  1369.                +---------------------------------------+
  1370.                | Data |  MI-Content | MI-Content | ... |
  1371.                | Type |    Field    |   Field    |     |
  1372.                +---------------------------------------+
  1373.                               |
  1374.                               |  Encapsulate Function
  1375.                               V
  1376.  
  1377.   +--------------------------------------------------------------------+
  1378.   | Crypto |  Content  |  Data  |  MI-Content  |  .. | MD-Content | .. |
  1379.   | Sync   |  Length   |  Type  |    Field     |     |   Field    |    |
  1380.   +--------------------------------------------------------------------+
  1381.                               |
  1382.                               |  Generate SDT PDU
  1383.                               V
  1384.  
  1385.      +--------------------------------------------------------------+
  1386.      | PID  |  Length  | PDU Type  | SAID  | Protected-Octet-String |
  1387.      +--------------------------------------------------------------+
  1388.                               |
  1389.                               |  Forward SDT PDU
  1390.                               V
  1391.  
  1392.                     +-------------------------+
  1393.                     |  DFP Header  |  SDT PDU |
  1394.                     +-------------------------+
  1395.  
  1396.  
  1397.                  Figure 7:  Encodings and Relationships
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416. K. R. Glenn          Expires: March 28,1994                    [Page 24]
  1417.  
  1418. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1419.  
  1420.  
  1421.                     +-------------------------+
  1422.                     |  DFP Header  |  SDT PDU |
  1423.                     +-------------------------+
  1424.                               |
  1425.                               |  Discard DFP Header
  1426.                               V
  1427.  
  1428.      +--------------------------------------------------------------+
  1429.      | PID  |  Length  | PDU Type  | SAID  | Protected-Octet-String |
  1430.      +--------------------------------------------------------------+
  1431.                               |
  1432.                               |  Decapsulate Function
  1433.                               V
  1434.  
  1435.      +--------------------------------------------------------------+
  1436.      |  Content  |  Data  |  MI-Content  |  ... | MD-Content | ...  |
  1437.      |  Length   |  Type  |    Field     |      |   Field    |      |
  1438.      +--------------------------------------------------------------+
  1439.                               |
  1440.                               |  Parse Unprotected-Octet-String
  1441.                               V
  1442.  
  1443.               +---------------------------------------+
  1444.               | Data |  MI-Content | MI-Content | ... |
  1445.               | Type |    Field    |   Field    |     |
  1446.               +---------------------------------------+
  1447.                               |
  1448.                               |  Send User Data to DFP
  1449.                               V
  1450.  
  1451.         +------------------------------------------------+
  1452.         |  DFP Header(optional) |        User Data       |
  1453.         +------------------------------------------------+
  1454.  
  1455.                  Figure 8:  Encodings and Relationships
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476. K. R. Glenn          Expires: March 28,1994                    [Page 25]
  1477.  
  1478. INTERNET-DRAFT               I-NLSP                    September 23,1993
  1479.  
  1480.  
  1481.                            References
  1482.                            ----------
  1483. [ISO8473]     ISO/IEC.  Protocol for providing the connectionless-mode 
  1484.               network service.  International Standard 8473, ISO/IEC 
  1485.               JTC 1, Switzerland, 1986.
  1486.  
  1487. [ISO8348Ad2]  ISO/IEC.  Information processing systems -- data 
  1488.               communications -- network service definition addendum 2:
  1489.               Network layer addressing.  International Standard 
  1490.               8348/Addendum 2, ISO/IEC JTC 1, Switzerland, 1988.
  1491.  
  1492. [ISO9972]     ISO/IEC.  Information technology - Data Cryptographic
  1493.               Techniques - Registration Procedures for Cryptographic  
  1494.               Algorithms.
  1495.  
  1496. [ISO11577]    ISO/IEC.  Information technology - telecommunications and
  1497.               information exchange between systems - network layer 
  1498.               security protocol.  Draft International Standard 11577, 
  1499.               ISO/IEC JTC 1, USA, November 1992.
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535. K. R. Glenn          Expires: March 28,1994                    [Page 24]
  1536.